[レポート][AWS] Fukuoka.dev #1 でクラウドネィティブな開発者向けの話を聞いてきました #fukuoka_dev

福岡だより

#勉強会

田中孝明

2019.07.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、CX事業本部の田中孝明です。

7/16(火) に株式会社Fusic様のセミナールームで開催された [AWS] Fukuoka.dev #1 - とりあえずクラウドネイティブ - についてのレポートです。

とりあえずサーバーレス

Amazon Web Services Japan K.K. 西谷圭介さん（@Keisuke69）

サーバーレスの Specialist Solution Architect
- Blog: Sweet Escape
- Blog: うどんか蕎麦だと蕎麦派のブログ
AWSのサービスを使うデベロッパーを対象にしている Meguro.dev というイベントをやっている
- Fukuoka.dev も同じく、福岡のデベロッパー向けのイベントをやりたい
  - ロゴが未定なので有志に募りたい

すべてサーバーレスでやろうではない

「お金で時間を買う」という考え方
AWS Lambda を利用することが絶対的にコストが安いわけではない
- 場合によっては ECS が安くつく
目指すべきこと
- いかに早く価値のあるシステムを作る
- 「差別化に繋がらない重労働」を「自分でやらない」

コンピューティングの進化

物理マシン
- プランニングに「推測」が必要
- 長時間かけて見積もりや調達を行う
- フィードバックサイクルが長い
仮想マシン
- ハードウェアとの独立性
- 迅速なプロビジョニング
- よりスケール
- Elasticなリソース
コンテナ
- プラットフォーム非依存
- 一貫したランタイム環境
- リソースの利用効率も高い
- 隔離とサンドサンドボックス
- 起動時の速度
サーバーレス
- 対象のサービス
  - AWS Lambda
  - AWS Fargate
- 連続的なスケール
- 幅広いプラットフォームの選択肢
- 仮想サーバの幅広い選択肢

おさらい：サーバーレスとは

自動でスケール
価値に対する支払い
オペレーションの責任範囲について
- お客様の管理範囲はアプリケーションコード
ECS と EKS を活用するケースがある
使い分けたいニーズがなければ、とりあえずサーバーレス（サーバーレスファースト）
- うまくいかなかったらコンテナ、EC2と検討していく
- 明確につかい分けたいニーズがある場合
- 特性に応じて幅広い選択肢から選択
悩んだらSolution Architectに相談してください

CacooにおけるコンテナとGoとgRPCなどの話

株式会社ヌーラボ木村（@cohhei）さん

クラウドネイティブやってますか

クラウドネイティブとは
- スケーラブルなアプリケーションを構築および実行するための技術の総称
- 代表的な技術：コンテナ、サービスメッシュ、マイクロサービス
- 回復性などのメリットがある
- コンテナ、CI/CD

Cacoo について

スライドも Cacoo で作る
CacooのバックエンドはほぼGoで作られえている
Fukuoka、NewYoke、Amsterdamのメンバーで作成している
分業について
- エディッター部分
  - 福岡チーム
- ダッシュボード部分
  - 海外チーム

Kubernetes

Kubernetesで実現している
- 複数のホストVMを抽象化
- ホストマシンはあくまでマシンリソースのプール
- ホストマシンのコモディティ化
- 特定のマシン固有の運用・管理は不要
- コンテナ・ホストのスケールが容易
Serviceによるロードバランシング
- Podへの通信を抽象化
- 共通のYAMLフォーマットで設定可能
- Podをスケールしやすい
Docker化していく
- 新しい機能を作るときにコンテナ化していく
- デザインのリニューアルに便乗して ECS のサービスを移行
EC2 → ECS → Kubarnetes
チームの依存関係が減った
部分的な変更がしやすくなった

GO

Goはクラウドネイティブとの相性がいい
muiti-stage builds
- buildしたやつをコピーできる

gRPC

オープンソースのRPCフレームワーク
遠隔手続き呼び出し
インターフェースをプロトコルバッファで自動生成
双方向のストリーミング
インターフェースはサーバー側で実装してあげると、他のサーバーで使える
ProtocolBufferスキーマを定義させることで、通信するレスポンスの型を定義できる
- 型がきっちりしているのがメリット

テストについて

単体テスト
- 同じサーバーインターフェースを満たすモックを実装
トランザクションはどうしている
- サービスをまたいだトランザクションは諦める
- アプリケーションレイヤーでトランザクションを頑張るのはお勧めしない
Cacoo における Protofiles と生成したコードの管理
- Protocol Buffersファイルとは単一のリポジトリで管理、ファイルが更新されると
- JenkinsでJavaとGoのコード生成
他のプロジェクトは dep ensure などで取得
Protofiles と生成されたコードのブランチは一致

いい感じにスケール

Cacooの開発組織は海外と福岡に分かれている
Kubernetesクラスタを EC2 で運用している
Goはいいぞ
gRPC使ってるよ

mockmockの大量のログをいい感じに捌きたい

株式会社Fusic 毛利さん

mockmock のプロダクトオーナー
好きなサービスKinesis

mockmock

IoT開発者向け擬似データサービス
IoTの開発でネックになりそうなところ
- IoTのデータを送ってほしい
- モノにだって都合がある
- エラーデータを出せない
シミュレータを作る
- 作った人にしか動かせない
- 思い通りになるモノを仮想的に作る

ログ処理機構

設定ファイルバイナリをDL
ログの処理機構
- 詳細なログを撮りたい
- ログのサイズは送信データサイズによって大きく変動
最大稼働数は実績で５万台
稼働数によって費用もスケールするように

第1世代方針

mockサーバーには何もインストールしない
監視とかアップグレードとかが面倒
ログ処理機構にネットワーク帯域を割きたく無い
Towor が 1分ごとに集計
- 送信ごとにログを書き出す
何もインストールしなくてもいい
- ログの処理機構に咲くネットワーク帯域が最低限
ログの伝達にやたら時間がかかる
ログの内容が必要最低限しか無いので、異常系まで考えるとログの集約処理が複雑になる

第2世代方針

ネットワーク帯域をある程度割くようにした
足りなかったらお金の力に頼っていこう
DynamoDB On-Demand を利用した
- キャパシティユニットをあらかじめ設定しておく必要がない
mock -> DynamoDB -> Streams -> Lambda -> SNS -> SQS ...
詳細ログが見れるようになった
- その代わり、ログ処理機構に咲くネットワーク帯域が大きくなった...
DynamoDB On-Demand はゴリゴリ使うと高い

第3世代方針

DynamoDBのキャパシティを確保
- 起動時に必要なキャパシティを予測できれば実現する
- 送信データサイズによってログのサイズが大きく変動
- 送信データサイズを予測するのは困難
- 送信データの部分だけ別の機構を使って保存すれば良いのでは
- キャパシティは増やす方向には回数制限がないけど、減らす方向には回数制限がある
Amazon Elastic File System を利用
- 複数のサーバーからマウントできる共有ストレージ
- 容量が自動でスケールする
- スループットが制御可能

第4世代方針（これから）

mockサーバーに何かをインストールするのを許容しよう
今こそ Kinesis と向き合おう
早くも EFS から脱却したい
Amazon CloudWatch Logs を活用する

第5世代方針（あわよくば）

Amazon Timestream を検討したい
- Preview 申請しているが...

always.fanで初Dockerにチャレンジ、ECSの導入における紆余曲折

イジゲン株式会社平野（@fm609hr）さん

Dockerにチャレンジした
- Docker / ECS / k8s なんとなく知っている方を対象に話します
イジゲン株式会社は大分の会社
- サービス always を作成しています
  - いろんなお店の定額サービスを提供・販売

歴史的経緯

採用について
- Chefに詳しいエンジニアがいない
  - 利用している人に出会えない
  - トラブルシューティングに時間がかかる
  - 成長スピード促進のための見直し

Docker環境への移行

コードベースでのインフラ管理
データ分析強化
AWSでのDocker環境
- ECS
- EKS
ECSを選択した
- 比較的敷居が低い
- Fargate も検討した

ECS

コンテナオーケストレーションサービス
クラスタ
- URLのマッピング
- Web/API
- Prd・Stg環境
サービス
- 複数のサービス・パスにマッピングなどを想定
- https://xxx/sv1
- https://xxx/sv2
タスク
- コンテナの実行
- 複数の組み合わせ可能
- スケーリング
  - コンテナ＃１
  - コンテナ＃２
タスク定義
- Dockerイメージの指定
- CPU/MEMの指定
- 環境変数など
アプリケーションと連携
- アップデート頻度高い

実際につまづいた点

ロギング
- awslofs で CloudWatch Logs に保存
- Lambdaで好みの場所に
EC2 の管理
- ECS用に Optimize された AMI を利用する
- 起動したEC2はスケールアップできない
- 新しいサイズのEC2を追加後、削除
- セキュリティアップデート
定期実行
- Scheduled Taskを利用
- Cloud Watch Events でタスクを定期的に実行
コンテナへのアクセス
- コンテナにアクセスしたくなることがある
- EC2 への SSH環境はあった方がよさそう
- セキュリティ的にはSSM経由がお勧め
Code Pipeline でビルド
- ローカル環境でイメージ作成
- CLI で ECR ログイン情報を取得しECR登録
タスク定義のCPU設定
- vCPU x 1024 の値が設定値
エラー対応
- 原因がタスク起動か、アプリケーションかを分別
- ECS のコンパネでタスク起動ログを確認
- 正常起動している場合はアプリケーションログを
- ヘルスチェックに失敗すると、タスクが再起動
  - WEBサーバー起動失敗 or ヘルスチェックパスの記述ミス